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Abstract 

S. Beckman and S. Darpel 



During the early development of products, flight, or experimental hardware, 
emphasis is often given to the identification of technical requirements, 
utilizing such tools as use case and activity diagrams. Designers and project 
teams focus on understanding physical and performance demands and 
challenges. It is typically only later, during the evaluation of preliminary 
designs that a first pass, if performed, is made to determine the process, 
safety, and mission/quality assurance requirements. Evaluation early in the 
life cycle, though, can yield requirements that force a fundamental change in 
design. This paper discusses an alternate paradigm for using the concepts 
of use case or activity diagrams to identify safety/hazard and mission/quality 
assurance risks and concerns using the same systems engineering 
modeling tools being used to identify technical requirements. It contains two 
examples of how this process might be used in the development of a space 
flight experiment, and the design of a Human Powered Pizza Delivery 
Vehicle, along with the potential benefits to decrease development time, and 
provide stronger budget estimates. 



The Problem 
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• Systems Engineering and Project Management Professional universally 
agree with the notion that the later a change to a design occurs, the higher 
the cost 

• Design changes are most often the result of a late identification of a 
requirement or a performance gap 

• Requirements definition in the early concept and design phases focuses on 
technical and performance items 

• Current paradigm ignores an entire grouping of requirements until well into 
the preliminary design phase, after decisions have been made about trades 
and architecture 


S&MA requirements not identified 
until the preliminary design phase 
yields additional redesign costs that 
could be avoided if done earlier 
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The Systems Engineering “V” Approach n*sa 
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The Systems Engineering “V” Approach n*sa 
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Where S&MA is 
usually brought in 


► 


Time 



S&MA Typical Involvement 



• S&MA discipline support ramps up with focus on analyzing the 
preliminary design 

- Preliminary Hazards Assessment 

- Environmental Testing 

- EEE Parts Plans & Searches 

- Required Margins 

- Identification of Standards 

- Materials Assessments 

• Requirements-based approach, leading a subtractive process that 
starts with a maximum set of items, tailoring down to an appropriate 
level 

- Takes a lot of time, effort 

- S&MA disciplines thought of more as a burden, adding work to a project 
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Impacts of Current Paradigm 



• Identification of hazards after preliminary designs means redesign to 
accommodate the required controls, at best 

• At worst, a complete redesign is required, when it cannot meet safety 
margins 
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An Ehnacned Systems Engineering “V” Approach 



Where S&MA should get involved with 
requirements definition. 
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Redefining of S&MA Value 



• S&MA Disciplines are currently utilized to identify issues with a 
design 

• Given that most hazards and QA requirements can be based on 
intended uses and activities, S&MA disciplines can help identify them 
during use case and concept of operations development 

• Earlier involvement of S&MA can reduce redesign and cost 

• S&MA discipline experts focused on risk 

- Help the project identify what the risks are 

- Which risks might be associate with hazards? 

- What good practices or additional requirements can be used to mitigate? 

- NOT focused on applying a standard set of requirements, but adding in only 
those that add value through the mitigation of risk 
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• A pizzeria owner in a large metropolitan area has his 
delivery person deliver pizzas one at a time on foot. 

• Pizza needs to arrive at a minimum temperature. 

• Radius of delivery is determined by speed of delivery 
person and time for pizza to cool to minimum temp. 

• He needs a way to deliver more pizzas faster to increase 
radius of delivery and thus his customer base to increase 
profits. 

• Since traffic congestion is an issue, a car is not a solution. 
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Example 

Human Powered Pizza Delivery 








Use Case Diagram 





Activity Diagram 
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Partial Requirements Set 
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Name 

Text 

1 

HPPDV1 

ns Carry Capacity 

The HPPDV shall carry at least two pizzas. 

2 

HPPDV2 

nn Speed 

The HPPDV shall be capable of traveling at a speed of at least TBD kph. 

3 

HPPDV3 

a Acceleration 

The HPPDV shall be capable of accelerating at a rate of TBD kph/sec. 

4 

HPPDV4 

a Deceleration 

The HPPDV shall be capable of decelerating at a rate of TBD kph/sec. 

S 

HPPDV5 

dl Maneuverability 

The HPPDV shall be maneuverable. 

6 

HPPDV6 

ms Mass 

The HPPDV shall weigh no more than TBD kg. 

7 

HPPDV7 

ms Size 

The HPPDV shall fit in an envelope no larger than X m by Y m by Z m. 
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Current Product Development Flow* 
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Current Product Development Flow* 
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Earlier Involvement Of S&MA 



• As use case or activity diagrams are developed, include S&MA 
disciplines 

• Looking at each use or activity, ask the questions 

- “Is there any way this can cause a hazard?” 

- “How can this go wrong?” 

• This early identification of risk can lead to additional technical, 
performance, and S&MA requirements 
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Use Case Diagram with S&MA input 




How can “Load 
Pizzas” go wrong? 
What are the risks 
associated with 
this interaction? 


New project requirement: System shall have features to secure loaded pizzas to 
prevent loss during delivery 


Activity Diagram with S&MA i 
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Activity Diagram with S&MA i 
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Activity Diagram with S&MA i 
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• Earlier identification of hazards will yield fewer design 
iterations. (Safety risks) 

• Earlier identification of assurance requirements will yield 
better understanding of testing needs. 

• Earlier involvement of S&MA disciplines during use and 
activity model development will yield better understanding of 

the system use 

• More effective S&MA plans 

• More appropriate S&MA requirements sets 

• Risk-based, additive approach leads to appropriate requirements sets 
better in line with risk posture 
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